Traditionally, personal computing hardware and software systems followed a model where trust decisions about software installed and run on such computer hardware were made explicitly by users of such systems. For instance, a user would install software by inserting a compact disk (CD) or other computer readable medium into his or her computer system. In such approaches, the user was responsible for the safety of the installed software, and for making decisions that the installed software did not contain malicious code, such as computer viruses, spyware, or other malicious software (malware).
This traditional trust model for software applications is no longer applicable when such software applications are delivered to computing systems via the Internet or the World Wide Web via, for example, a web browser, or via other mechanisms, such as described herein. As an application platform, the modern web browser brings together a remarkable combination of resources, including seamless access to Internet resources, including access to a wide variety of application software. This approach, however, creates the opportunity for malicious software/code to be easily delivered to, and installed on a user's computing system.
One problem with delivery of software applications (executable content) in these manners is that such content may easily exhibit malicious behavior (e.g., corrupting a computing system). Two common approaches to prevent programs from expressing such malicious behavior are interpreted languages, such as JavaScript and type-safe languages, such as C# and Java. In these approaches, the languages are designed in such a way that certain dangerous constructs are excluded, such that said constructs cannot be used to express a malicious operation. Examples of dangerous constructs include inline assembler, self-modifying code, type casts, pointer arithmetic, and traditional malloc/free heap management. While improving program safety, these restrictions also tend to impact performance and developer productivity and preferences.
In the case of interpreter-based language implementations, safety relies on correct (e.g. bug-free) implementation of the interpreter. In the case of language implementations that use a bytecode language or intermediate representation, safety typically relies on the correct implementation of the bytecode compiler or interpreter. These compilers and interpreters are commonly large and complex software systems, and are rarely defect free. As such, they constitute a large attack surface for an attacker.
One approach that is used to overcome the performance limitations of using interpreted languages for browser-based applications is the use of various extension mechanisms such as ActiveX and NPAPI plug-in environments. Such plug-in environments allow native code (e.g., machine instructions of the specific computing system) to be loaded and run in a browser as part of a web (browser-based) application. While such architectures allow browser-based applications to achieve the computational performance characteristics of native applications, they do so at expense of allowing the browser-based applications to circumvent the security mechanisms otherwise applied to web content using, for example, interpreted languages and/or secure runtime environments.
Google Native Client provides computer users protection from malicious code using measures, such as validating and isolating or “software-sandboxing” native client code, which allow native code to be run within a browser in a secure and safe fashion. Such methods have been described, for example, in the following applications, all of which are hereby incorporated by reference in their entirety: “Method for Validating an Untrusted Native Code Module,” application Ser. No. 12/117,634, filed May 8, 2008; “Method for Safely Executing an Untrusted Native Code Module on a Computing Device,” application Ser. No. 12/117,650, filed May 8, 2008; “Native Code Module Security for ARM Instruction Set Architectures,” application Ser. No. 12/621,286 filed Nov. 18, 2009, and “Native Code Module Security for 64-bit Instruction Set Architectures, application Ser. No. 12/621,266 filed on Jul. 31, 2009.